edges, err := e.getters.GetDependencies(ctx, scope.Version.Id)
	if err != nil {
		span.RecordError(err)
		return results.NewDeniedResult(
			fmt.Sprintf("Deployment dependency: failed to load dependencies: %v", err),

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@apps/api/openapi/openapi.json`:
- Around line 5320-5514: You changed the dependency endpoints from
/v1/workspaces/{workspaceId}/deployments/{deploymentId}/dependencies... to
/v1/workspaces/{workspaceId}/deploymentversions/{deploymentVersionId}/dependencies...,
which is a breaking v1 API change; restore a deprecated compatibility shim by
reintroducing the original routes (the /deployments/{deploymentId}/dependencies
paths) and have them delegate to the new handlers (reuse the logic behind
operationId listDeploymentVersionDependencies,
requestDeploymentVersionDependencyDeletion, and
requestDeploymentVersionDependencyUpsert) while marking those old paths
deprecated in the OpenAPI spec and adding a comment/response header indicating
deprecation and migration instructions for one release cycle.

In `@apps/api/src/routes/v1/workspaces/deployment-versions.ts`:
- Around line 210-214: The async calls to enqueueReleaseTargetsForDeployment are
currently fire-and-forget and can cause unhandled rejections; update each call
site that currently calls enqueueReleaseTargetsForDeployment(db, workspaceId,
found.deployment.id) (and the second similar call later in the file) to
explicitly handle the returned promise using the non-blocking pattern: void
enqueueReleaseTargetsForDeployment(...).catch(err =>
logger.warn("enqueueReleaseTargetsForDeployment failed", { err, workspaceId,
deploymentId: found.deployment.id })); use the existing logger variable in this
module so the call remains non-blocking but any rejection is logged.

In `@packages/db/drizzle/0191_equal_talisman.sql`:
- Around line 1-6: The join table deployment_version_dependency lacks workspace
scoping: add a NOT NULL workspace_id uuid column, include workspace_id in the
primary key (so PK becomes (workspace_id, deployment_version_id,
dependency_deployment_id)), and add foreign key constraints that pair
workspace_id with each id (e.g., (workspace_id, deployment_version_id) ->
deployment_version and (workspace_id, dependency_deployment_id) ->
deployment/deployment_version as appropriate) to enforce tenant isolation;
update constraint names to reflect the new PK/FK columns.
- Line 8: The migration currently drops the legacy table via DROP TABLE
"deployment_dependency" which will lose all existing dependency rows; instead,
implement a data migration that preserves existing data by selecting from
deployment_dependency and inserting into deployment_version_dependency (mapping
columns and foreign keys as needed), validate and backfill any new
columns/defaults, and only drop "deployment_dependency" after successful
copy/verification (or keep it as a fallback). Update the migration that contains
DROP TABLE "deployment_dependency" to perform: 1) create any missing
columns/indexes on deployment_version_dependency, 2) insert transformed rows
from deployment_dependency into deployment_version_dependency, 3) verify
counts/constraints, and finally 4) drop the legacy table (or mark it deprecated)
— reference the table names deployment_dependency and
deployment_version_dependency and the DROP TABLE statement to locate where to
apply these changes.

In `@packages/db/src/schema/deployment-version.ts`:
- Around line 69-83: The table definition deploymentVersionDependency is missing
workspaceId which allows cross-tenant edges; add a workspaceId column (uuid
referencing workspace.id with notNull and onDelete cascade), include workspaceId
in the primaryKey alongside deploymentVersionId and dependencyDeploymentId, and
update the migration/schema to create that column and constraint; also update
any insert/update code paths that write to deploymentVersionDependency (and any
relational helpers) to set and validate workspaceId equals the workspaceId of
deploymentVersionId and dependencyDeploymentId so the same-workspace invariant
is enforced at write time.

---

Nitpick comments:
In `@apps/api/openapi/openapi.json`:
- Line 5320: The spec is exposing two inconsistent path styles for the same
resource
("/v1/workspaces/{workspaceId}/deploymentversions/{deploymentVersionId}/dependencies"
vs "/v1/.../deployment-versions/{deploymentVersionId}/user-approval-records");
pick one canonical path style (either "deployment-versions" with hyphen or
"deploymentversions" without) and update all new endpoints to match it. Rename
the new path(s) and their operationId/route names to use the chosen style,
update any schema $ref/parameter references that point to the old path, and
adjust related tests, client generators, and docs to use the single consistent
path (ensure you also change the duplicate occurrence around lines referenced by
the reviewer).

In `@apps/workspace-engine/pkg/db/deployments.sql.go`:
- Around line 81-82: Remove the redundant explanatory comment above the
generated query accessor in apps/workspace-engine/pkg/db/deployments.sql.go (the
line "Dependencies are pinned per deployment_version, so this returns the dep
edges that belong to a single deployment_version row."); since the
function/query name already conveys this, delete that comment so the generated
accessor remains concise and free of restating-comments.
- Around line 127-132: The query in the GetDeploymentsWithVersionsDependingOn
SQL constant uses SELECT DISTINCT without ORDER BY, causing non-deterministic
row ordering; make results deterministic by adding an ORDER BY clause (e.g.,
ORDER BY dv.deployment_id) to the SQL in GetDeploymentsWithVersionsDependingOn
so callers receive a stable, predictable sequence of deployment IDs.